Many authentication or validation systems are dependent on processing one or more inputs in the same way or nearly the same way, or in corresponding or coordinated ways, at different locations and/or at different times, and then following up based on the results.
For example, a lossless data compression/decompression system may be used in a situation in which a compressed version of an original file may be derived at one location and may then be transmitted to another location where a decompressed version is derived from the compressed version. For the lossless aspect of the system to work properly, i.e., for the decompressed version to match the original file and therefore be valid, the compression and decompression processes must work reliably in corresponding ways so that data corruption is not introduced.
Identity authentication is another example. Methods for authenticating an identity of an entity are known that are based on something the entity knows, something the entity has, a biological characteristic of the entity (sometimes referred to as something the entity is) or some combination of those things. One such computer-based authentication method involves the communication of a secret that is unique to a particular entity or user. The entity that is seeking authentication transmits the secret to a verifier who authenticates the identity of the entity. Typically, an entity communicates both identifying information (such as a user name) and a secret (such as a password) to the verifier. The verifier typically possesses records that associate a secret with each entity. If the verifier receives a secret that matches an appropriate record, the authentication of the entity is successful. If the verifier receives an incorrect secret, the authentication fails.
Time-based authentication systems also associate an entity with a secret, typically a number, which is unique to that entity. These systems generally perform some algorithmic processing of the secret to generate an authentication code that is ultimately used to authenticate the entity. Some time-based systems use a dynamic variable to calculate a non-predictable authorization code that ultimately authenticates the entity. Here, “non-predictable” means that the authorization code is not predictable by a party that does not know the associated secret, the algorithm for calculating the code, or both. The dynamic variable may comprise any code, typically a number, which is defined and determined by the interval of time in which an authentication code is generated. The dynamic variable can change according to any interval of time, e.g., 2 minutes, 5 minutes, 1 hour and the like. Because in these systems the authentication code changes from time to time, intercepted authentication information has a limited value because it cannot be used for authentication in the future.
The user may employ a device to algorithmically compute the correct authentication code for a particular time. The algorithm is typically provided to the user in the form of a hardware token loaded with a program for carrying out the predetermined algorithm, although it may be provided as software executing on a general-purpose computer. The device may also allow the user to input a second, personally selected secret, such as a personal identification number (PIN) in order to generate a correct authentication code. Only a correctly entered PIN produces a correct authentication code for a particular time. One such device is the SECURID authentication token, available from RSA, The Security Division of EMC, of Bedford, Mass. These devices can display the generated authentication code to the user, who may then communicate the authentication code to the verifier.
For the authentication to work properly, the token at one end and the verifier at the other end must work reliably in the same way at least for algorithmic processing of inputs.
Transaction signing is another example. It has become widely accepted to conduct transactions such as financial transactions or exchange of documents electronically. Automated teller machines (ATMs) and credit cards are widely used for personal transaction and as their use expands so too does the need to verify such transactions increase. A smart card is somewhat like a credit card and includes some processing and storage capability. Smart cards are prone to fraudulent misuse. For example by a dummy terminal which is used to glean information from an unsuspecting user. Thus, before any exchange of critical information takes place between either a terminal and smart card or vice versa it is necessary to verify the authenticity of the terminal as well as the card. One of these verifications may take the form of “signing” an initial transaction digitally so that the authenticity of the transaction can be verified by both parties involved in the subsequent session. The signature is performed according to a protocol that utilizes a random message, i.e. the transaction and a secret key associated with the party.
The signature must be performed such that the party's secret key cannot be determined. To avoid the complexity of disturbing secret keys, it is convenient to utilize a public key encryption scheme in the generation of the signature. Such capabilities are available where the transaction is conducted between parties having access to sufficient computing resources.
For the transaction signing to work properly, signing at one end and verification at the other end must work reliably in the same or corresponding ways at least for the protocol or encryption scheme processing of inputs.